home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / opushelp.arc / OPUSHELP.DOC
Encoding:
Text File  |  1987-07-28  |  6.8 KB  |  198 lines
  1.  
  2.                     Opus 1.0 Simple Help Documentation
  3.                                     by
  4.                         Bob Hartman (node 132/101)
  5.                                      
  6. In the  past 2  1/2 weeks I have received a lot of phone calls and messages
  7. about problems  that people  have had  with oMMM and/or Opus 1.0 (or 1.01),
  8. and I decided that I would finally create a document to help matters just a
  9. bit.   Below you  will find some problems, then the solutions for them.  If
  10. you have something that isn't answered here, please send a message to David
  11. Finster at OpusInfo (node 124/111 primary address).
  12.  
  13. Problem #1:
  14.  
  15.      I am not sending out ARCmailed packets like I am supposed to.
  16.  
  17. Solution:
  18.  
  19.      You need  to have one of the following statements in your oMMM control
  20.      file:   ArcTo, Hold,  Crash.  All three do ARCmailing, and the keyword
  21.      used determines  whether it  will be  a normal  ARCmail file,  a  held
  22.      ARCmail file, or a Crash ARCmail file.
  23.  
  24. Problem #2:
  25.  
  26.      I am trying to poll a node, but I call his network host instead.
  27.  
  28. Solution:
  29.  
  30.      You are  probably using  something  like  the  following  sequence  of
  31.      statements:
  32.  
  33.           POLL x/y
  34.           ...
  35.           ROUTE
  36.  
  37.      What you  are doing  is creating a .OUT file (via the POLL statement),
  38.      but then  you are  host-routing the  .OUT file  when you use the ROUTE
  39.      statement.   The trick  is to  make the  .OUT file into something else
  40.      that will not be ROUTE'd.  Try the following:
  41.  
  42.           POLL x/y
  43.           DIRECT x/y
  44.           ...
  45.           ROUTE
  46.  
  47.      This way  the .OUT file is converted into a .DUT file before the ROUTE
  48.      statement gets  executed.   ROUTE (like most other oMMM control verbs)
  49.      only works on .OUT type files.
  50.  
  51. Problem #3:
  52.  
  53.      My nodes that I hold for are having their messages lost.
  54.  
  55. Solution:
  56.  
  57.      This can happen a couple of ways, but the most common that I have seen
  58.      is the case where there is a line in the oMMM control file like:
  59.  
  60.           HOLD x/y a/b c/d ...
  61.  
  62.      If you  read the  documentation  carefully  you  will  see  that  this
  63.      statement causes  mail for  a/b, c/d  and the  rest to be placed in an
  64.      archive that  is held for node x/y.  What you really want is something
  65.      like:
  66.  
  67.           NormHold x/y a/b c/d ...
  68.  
  69.      The above  statement is  used if  you  do  not  want  to  ARCmail  the
  70.      messages, if you do want to ARCmail them, then use:
  71.  
  72.           OneHold x/y a/b c/d ...
  73.  
  74. Problem #4:
  75.  
  76.      My forced  Z-event for  sending only  crash mail  does not  seem to be
  77.      working properly.
  78.  
  79. Solution:
  80.  
  81.      This is  a particulary  nasty problem.   As  far as  I can tell (and I
  82.      might be wrong on this, but it seems to hold as far as I can test it),
  83.      a FORCED event will happen EXACTLY ONCE.  So, lets say that you have a
  84.      forced Z-event that runs from 1:00-3:00.  At 1:00 it runs and converts
  85.      you to  a crash  only system.   Now  at 2:00 you exit the system to do
  86.      some maintenance  and start  it up again.  Well, your forced event has
  87.      already taken  place, and  won't be  done again.   You end up with the
  88.      default Z  event from  your control  file.   The  solution  is  rather
  89.      simple:
  90.  
  91.           Z-events should NEVER BE FORCED events.
  92.  
  93.      This way  they simply  get noticed  whenever Opus  is checking on what
  94.      event it  is executing,  and the change will take place.  Like I said,
  95.      this one is particulary nasty since it sort of goes against the normal
  96.      train of thought.
  97.  
  98. Problem #5:
  99.  
  100.      My system  does not  seem to unpack any mail packets that it receives.
  101.      I see  the .PKT  files in  the inbound  file area,  but  then  nothing
  102.      happens to them.  I use FastToss (or ConfMail) to toss the rest of the
  103.      echomail, but still the .PKT files remain.
  104.  
  105. Solution:
  106.  
  107.      Unfortunately, it  appears that  Opus will  only unpack  mail  if  the
  108.      switch to  Extract ARCmail  or the switch to Toss Echomail is enabled.
  109.      If you  don't use  FastToss or  ConfMail, then the solution is just to
  110.      enable one of those options.  If you do use FastToss or ConfMail, then
  111.      the following batch file workaround should do the trick:
  112.  
  113.           COPY inbound_dir\*.PKT opus_root_dir
  114.           DEL  inbound_dir\*.PKT
  115.           FastToss -N -A   or   ConfMail Import -N -A
  116.  
  117.      This will move those .PKT files to a location where either FastToss or
  118.      ConfMail will be able to extract them.
  119.  
  120. Problem #6:
  121.  
  122.      My events are executing at the wrong times.
  123.  
  124. Solution:
  125.  
  126.      This is  caused by an improper setting of the TZ environment variable.
  127.      Set your  system clock  to the  same time as the clock on the wall and
  128.      experiment with  the TZ  environment variable.   Currently  we are  in
  129.      Daylight Savings Time, and TZ=EDT4 works here on the East coast.
  130.  
  131. Problem #7:
  132.  
  133.      I can't exit from the C)hange menu.
  134.  
  135. Solution:
  136.  
  137.      This is caused by having the Opus 0.0 privilege files in place instead
  138.      of the  Opus 1.0  privilege files.   You  will  need  to  replace  the
  139.      CHGPRIV.BBS file.   Another  method that  I have heard will work is to
  140.      get into  the !)Sysop  menu and  alter the  privileges for the C)hange
  141.      menu.   When Opus  re-writes the file it is in the proper format again
  142.      (supposedly - you would have to try this yourself to verify it).
  143.  
  144. Problem #8:
  145.  
  146.      I can't get Wxmodem or CKermit to work with Opus 1.0.
  147.  
  148. Solution:
  149.  
  150.      You are  quite correct.  Wxmodem and CKermit were flakey at best under
  151.      Opus 0.0,  and officially  are not  even supported there.  There is no
  152.      new Wxmodem  for Opus  1.0, but  there is  a new  Kermit in  the  file
  153.      OKER_100.ARC.   It uses the new external program interface provided by
  154.      Opus and described in the file OREF_EXT.ARC available from 150/1.
  155.  
  156. Problem #9:
  157.  
  158.      I can't  X)port messages  from the  Matrix area,  but I can from other
  159.      areas.
  160.  
  161. Solution:
  162.  
  163.      Use the !)Sysop menu to change privileges in the M)atrix menu.
  164.  
  165. Problem #10 (a late addition):
  166.  
  167.      My HOLD  statement doesn't  seem to  be having any affect.  I have the
  168.      following in my oMMM control file:
  169.  
  170.           ArcTo x/y
  171.           Hold x/y
  172.  
  173. Solution:
  174.  
  175.      You are  running into the problem of dealing with oMMM as a sequential
  176.      processor.   Both ArcTo,  and Hold  create ARCmail for the given node.
  177.      Since the ArcTo statement is executed first, there is nothing left for
  178.      the Hold statement to work on.  There are two possible ways around the
  179.      problem:
  180.  
  181.           Hold x/y
  182.  
  183.      Which does  what you want the above two to do anyway.  Or, if you need
  184.      to do some more processing between the statements, perhaps:
  185.  
  186.           ArcTo x/y
  187.           ...
  188.           NormHold x/y
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.